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(54) Data processing system 

(57) A method and system provides a prototypical 
object 220 which can be copied to create a derived 
object. A derived object can contain attribute values or it 
can hold a reference to its prototypical object- If a 
required value is not held by the prototypical object, the 
object searches up an object hierarchy to find the 
required attribute. In addition, each object can register 
an interest in a prototypical object that contains required 
attributes, if an attribute of a prototypical object 
changes, the prototypical object informs all registered 
objects of the change. At runtime, the prototypical 
object becomes a master object whose attribute values 
can be changed by the user, whereby changes in mas- 
ter object attributes are propagated to all registered 
derived objects. 
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mand l.ne interface ("CLI"). A typical CLI consist <rf a ora^T '"^ command s to the OS using a com 
issue a command to the operating system by fy^ the nS !oraZ^ °" C ° mpUtaf SCreea 7716 user 
key to send this input to the OS. The OS would then proce^ the ISZ^??™"" pressina - « "^ nter " 

Later, more advanced OSs were developed JhLh ° 7-^1 command and respond accordingly, 
mouse or other form of pointing ^J^S^J^g^™ ( " GU ^ 'Nation with a- 

as an arrow on the computer screen. In add-on. the computer Seen £!2 ? h* Wh ' Ch is P° rtra ^ 

reg 10n represents different aspects of the computer sSSXS Se OS I Jr* ,nt ° different re9ions - wherein «*, 
computer system by using the mouse to ma?thTc2S^.^^ r S^?? n Pr ° 9ram - 7716 US6r ««* 

Current state of the art GUIs utilize an object orienS det fan T^S, ! 9 " ^ S6 ' eCtin9 9 desifed °P era «°n- 
and des,gn method in which program elements are ^Sl^t^ t * ject oriented " ^fers to a programming 
and multiple classes are linked by inheritance reWoSET^ S° P * J6CtS ' ° bjeCtS are instances of "asses 
of that Cass within the computer system. The £JSI£ Jf£ 22? ' ^ °' attributes ^fine the purple 
shared and propagated either upward or downward wZSlSS^^" *, h ' erarchical and Abates may be 
mmg and design, the reader is referred to Grady Booch ObleSen^ S e *P la ™tion of object oriented program- 
•s assumed that the reader of the present applied 'tlamZ^L * T' 9 " Wth Wkxtions, pp. 25-74. 1991 . , t 

In object oriented GUIs such as IBM's OsTob ^ i ! C ° ntentS ° f this do ~ment. 

background object on which ^.ctJ^^^^J^^ a * bit ™P* « *. computer screen. The 
mouse to perform actions on them. For examp.eThe uYe TeL m * * UMr ma ™P ula '^ objects by using the 
frame object. This type of GUI is preferable because a 1 SeS of a n°,T ° ^ * ^ or move a 
related to each other. Thus, a user can control a^fcSiTof^^l ^ either 0f the same «*« or 
press,ng a button by clicking the mouse over it particular type by using the same methods e g 

ar£S^ 

OODEs typically have a palette of objects with which the Iv^rl -w ° PSr t0 CTeate object orient «J programs 
djfferent and serves as a template for' the develop ^Z^^SS?^ ° n * 

ob ect. To use an object on the palette, the developer c32lhS£5 2 otr-L^ 95 ^ the defaU ' f Settin 9 s for tha * 
of^etteob^isc^ 

attnbutes for that particular object type. Typical properSls for an 523? * e V"** 18 a list of all the modifiable 
when selected. The developer can change object ind^duX or bv 2^ * SiZe ' font ' co,or and *<*™ 

attnbutes common to the objects. However. thi VZZSZZ "o flZl 222,' ^ ° f ° bjeCtS and the 
developer must either spend considerable time editing ££? LfJ^T * a ° d fuming. The 

tionally changing certain attributes. 9 ° bjeC1 ,nd,v,dua,, y °' group the objects and risk uninten- 

when a u ser exacu.es an application ^^^^1^5,7' c rr er,etI "* • version. Thus! 

Ins a, ,e"r=r^Se:*r "° m «** saia **- - in ea« ofciec h,v» chy ana ^ 

bv -^SKZ^rSS? '^"^o.^.iea.o^a^.e 

cei^SSs^^p^^ «--« o, ea M p r o Ktyp i ca , 

II ■ also preferred that tnere are object r^istraSeanstfrL^ ^ P'°" te havl ' n » at leas ' "» 
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inheritance, characterised by the steps of: 

creating a prototypical object in said object hierarchy; 

deriving a derived object having at least one attribute from said prototypical object; and 
searching said object hierarchy to retrieve a value for said attribute of said derived object. 
Following such an approach, an application developer may easily and efficiently change the attributes of application 
objects, and an application user may easily and efficiently change the attributes of application objects at runtime. In 
addition object oriented applications may be closely integrated with the desktop. The invention typically finds application 
in, and effectively provides, an object oriented development environment including an object hierarchy and techniques 
for propagating values via property inheritance. 

Thus in a preferred embodiment, a prototypical object is provided which may be copied to create a derived object. 
The derived object may contain attribute values or it can hold references to prototypical objects. If a required value is 
not held by a prototypical object, the object searches up an object hierarchy to find the required attribute. In addition, 
each object may register interests in prototypical objects. If an attribute of a prototypical object changes, the prototypical 
object informs all registered objects of the change. At runtime, the prototypical object may become a master object 
whose attribute values can be changed by the user. Changes in master object attributes are propagated to ail registered 
derived objects. 

From another aspect, the invention provides a data processing system for processing an object oriented develop- 
ment environment said system comprising: 

a central processing unit for processing said object oriented development environment; 
display means for displaying said object oriented development environment; 

an object hierarchy utilizing property inheritance, said object hierarchy associated with said object oriented 
development environment; 

a prototypical object in said object hierarchy; 

a derived object derived from said prototypical object, said derived object in said object hierarchy and having at 
least one attribute; and 

attribute delegation means associated with said derived object for retrieving a value of said at least one attribute 
by searching said object hierarchy for said value. 

An embodiment of the invention will now be described in detail by way of example only, with reference to the follow- 
ing drawings: 

Figure 1 is a diagram of computer system hardware; 

Figure 2 is a pictorial representation of an object oriented developing environment as displayed on a computer 
screen; 

Figure 3 is a pictorial representation of an attribute sheet for a button object as displayed on a computer screen; 
and J / 

Figure. 4 is a flow chart representing the steps followed when an object searches the object hierarchy for an 
attribute value. 

A representative hardware environment for practicing a preferred embodiment of the present invention is depicted > 
in Figure 1, which illustrates a typical hardware configuration of a workstation having central processing unit 10, such 
as a conventional microprocessor, and a number of other units interconnected via system bus 12. The workstation 
shown in Figure 1 includes random access memory ("RAM") 14, read only memory ("ROM") 16, and input/output ("I/O") 
adapter 1 8 for connecting peripheral devices such as disk units 20 and tape drives 40 to bus 1 2, user interface adapter 
22 for connecting keyboard 24, mouse 26, speaker 28, microphone 32, and/or other user interface devices such as a 
touch screen device (not shown) to bus 12, communication adapter 34 for connecting the workstation to a data process- 
ing network, and display adapter 36 for connecting bus 12 to display device 38. 

The display of an object oriented developing environment ("OODE") is shown in Figure 2. Displayed is toolbar 210 
containing a palette of objects and "card" 212 onto which the objects can be copied. The objects in the palette include 
rectangle 214, ellipse 216, text input field 218 and button 220. 

Each object 214-220 on toolbar 210 is a prototypical object of a static class. A "class" is an abstract concept mean- 
ing a set of objects that share a common structure and behavior. A "static" object is an object whose structure and 
behavior are fixed. A prototypical object is an instance of a class. That is, the prototypical object has the structure and 
behavior defined by the class. Again, for a better understanding of object-oriented design and programming, the reader 
is referred to the Booch text cited above. 

Each prototypical object 214-220 has one or more attributes. The number and type of attributes depends on the 
object's class. For example, button object 220 can contain attributes such as background color, button action and size. 
Rectangle object 214, on the other hand, can contain attributes such as fill color, contents, border type and size. 

Card 212 is the place onto which prototypical objects 214-220 are copied in order to build an object oriented appli- 
cation. A card is also an object. Typical OODEs allow applications to be built from a group of cards, called a "stack." The 
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stack is arranged in a certain order so as to control program flow. Various program objects, such as buttons, bring cer- 
tain cards to the top of the stack. The card at the top of the stack is displayed to the user on display device 138. 

The OODE allows a program developer to create cards and then place objects on the cards. After the developer 
creates card 212, the developer can copy prototypical objects 214-220 from toolbar 210 onto card 212. These copied 
5 objects are called "derived" objects. Derived objects are of the same class and instance as the prototypical object from 
which they were derived and take all of their attribute information from the prototypical objects. 

Both prototypical and derived object attributes can be changed by calling up an attribute sheet for an object or 
group of objects. The attribute sheet contains a list of the object attributes for that object. If the sheet for a group of 
objects is called up, only the attributes that are common to the group will be on the sheet. Using this sheet the user can 
io edit the attribute values of an object. 

Attribute sheets are comprised of stacks of card objects like card 212. Each card enables the editing of a specific 
attribute and is accessed by selecting a tab object located on the card. When the tab is selected, the associated card 
is brought to the top of the stack. Once the card is on top of the stack, the other objects on the card can be manipulated 
to set an attribute value. 

is Figure 3 depicts top card 310 of the attribute sheet for button object 220. Button 220 has one attribute: background 

color. This attribute is indicated by tab 31 2 associated with the top card 310. To change the background color for button 
object 220 the developer selects tab 31 2 on attribute sheet 310, then the developers selects a color from the displayed 
palette of rectangle objects 316. After a color is selected, the developer can edit the color by pressing button 318, select 
the color by closing the attribute sheet using window button 324 or cancel the selection by pressing button 320. 

20 Each attribute sheet also has register button 326. The user selects register button 326 to register that particular 

attribute in a prototypical object. If an attribute is registered in a prototypical object, the user will not be able to edit the 
other values of the attribute on its tabbed page. 

Each prototypical object 214-220 maintains a list of all derived objects which have registered an interest in it. If an 
attribute value of a prototypical object 214-220 is changed, the new attribute information is passed to all derived objects 

25 which are registered in that prototypical object, tf a registered derived object has one of the changed attributes, it will 
update that attribute as necessary. 

If the OS or a program requires a derived object's attribute value, that object will search its hierarchy to get the value 
for that attribute. Figure 4 is a flowchart which shows how an object will retrieve a required attribute. Initially, at step 410, 
the object will check itself for the attribute value. At step 412, the object looks to its registered prototype for the attribute 

30 value. At step 41 4, the object looks to its containment parent, e.g., the card containing the object. At step 41 6, the object 
looks to the class prototype. At step 418, the object looks to the user's desktop settings. If the attribute value is found 
in any of the prior steps, the object will use that value. Otherwise, the object will check with the user profile (step 420), 
which always contains values for all attributes. /ipj 

The following example shows how a preferred embodiment of the present invention is implemented in the C++ pro- 

35 gramming language. For a complete understanding of C++, the reader referred to M. Ellis & B. Stroustrup, The Anno- 
tated C++ Reference Manual, Addison-Wesley Pub. Co., 1990; it is assumed that the reader of the present application 
is familiar with the contents of that manual. The following code describes a class for a button object: 

40 *class Button 

{ public: 

Color GetBackgroundColor {) ; 

void SetBackgroundColor ( ) ; 
45 void SetBGColor Prototype {) ; 

private: -, ;. ; ^r-. . - 

Color f Background; 

so static Button fClassPrototype ; \ 

f BGCoiorProtocype ; 
Button parent; 

Is 

55 ' 

Note that this button contains only one attribute: background color. Of course, in practice a button might have any 
number of attributes. However, only one is necessary in this example of the present invention. The button has three pub- 
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lie functions: GetBackgroundColorQ, SetBackgroundColorO and SetBGColorPrototype(). In addition, the button has 
four private variables: "f Background," "fClassPrototype," fBGColorPrototype," and "parent." 
The following code describes the class of a prototypical button object: 

class Button/Tool 

{ public: 

Button f Bu ttonPrototype ; 



This prototypical object has one public variable: "f Button Prototype." Because this variable is an object of class Button, 
is it has all of the attributes and variables set out in the above definition of class Button. 

in an OODE, an object of class ButtonTool is placed on toolbar 210. This object serves as prototypical button 220. 
When the developer copies this object for use on card 212, the OODE automatically creates a derived object identical 
to "fButtonPrototype" and places it on the card (not shown). The derived object has the same attribute values as proto- 
typical button 220 

20 In class Button, an object's background color is held by the "fBackground" variable. The "SetBackgroundColorO" 

function sets this variable. The "GetBackgroundColorO" function retrieves an object's background color. If a color value 
is not held m 'fBackground" (step 410), the function looks to the registered prototypical object contained in "fBGColor- 
Prototype" (step 412). Next, the function will look to the object's containment parent as held by the "parent" variable 
(step 414) After the parent, the function will look to the class prototype as held in "fCIassPrototype" (step 416). If none 

25 of the objects in those variables contain a background color value, the function will automatically check for a value in 
the desktop (step 418). If the desktop does not contain a background color, the function will check with the user profile 
(step 420). The user profile contains a value for every object attribute. 

The "SetBGColorPrototypeQ" function registers an interest in a prototypical object and sets the "fBGColorProto- 
type" variable. If there is an existing registered prototypical object, it will deregister that interest 

30 As mentioned above and shown in Figure 3, the developer can change a derived object's attribute values by editing 
that object's attribute sheet or by changing an attribute in a registered prototypical object. When an attribute value of a 
prototypical object is changed, that object causes an "Object Changed Event" message to be sent to ail registered 
objects. The registered derived objects receive this message and update their variables accordingly. 

When the developer has finished developing the application, the developer uses the OODE to convert the devel- 

35 oped application into a runtime version. During this conversion, the prototypical objects become master objects. The 
attributes of the master objects can be edited by the application user. This way, a user can easily change the attributes 
of a particular group of objects by changing the master object. Of course, the user can also change the program objects 
individually 

40 Claims 

1. A data processing system having an object oriented development environment including an object hierarchy utiliz- 
ing property inheritance, said system being characterised by: 
a prototypical object (220) in said object hierarchy; 

a derived object derived from said prototypical object, said derived object being in said object hierarchy and 
having at least one attribute (312); and 

attribute delegation means associated with said derived object for retrieving a value of said at least one 
attribute by searching said object hierarchy for said value. 

so 2. The data processing system of claim 1 , wherein said object hierarchy further comprises a containment parent of 
said prototypical object. 

3. The data processing system of claim 1 or 2. wherein said object hierarchy further comprises a static class prototype 
for said prototypical object. 

55 

4. The data processing system of any preceding claim, wherein said object hierarchy further comprises a desktop. 

5. The data processing system of any preceding claim, wherein said object hierarchy further comprises a user profile 
having at least one attribute. 
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The data processing system of any preceding claim , further comprising object registration means for registering 
an interest of said derived object in said prototypical object. 

The data processing system of any preceding claim, further comprising conversion means for converting an appli- 
cation developed with said object oriented development environment into a runtime application having master 



objects. 



8. An object oriented development, environment adapted for use in the data processing system of any preceding 



claim 



57. A method of developing an object oriented application, adapted for execution on a data processing system, in an 
object oriented development environment including an object hierarchy utilizing property inheritance, characterised 
by the steps of: 

creating a prototypical object in said object hierarchy; 
75 deriving a derived object having at least one attribute from said prototypical object; and 

searching said object hierarchy to retrieve a value for said attribute of said derived object. 

10. The method of claim 9, wherein said object hierarchy comprises a containment parent of said prototypical object. 

20 11. The method of claim 9 or 10, wherein said object hierarchy comprises a static class prototype for said prototypical 
object. 

12. The method of any of claims 9 to 1 1 , further comprising the step of registering an interest of said derived object in 
said prototypical object. 

13. The method of any of claim 9 to 12, further comprising the step of converting said application developed with said 
object oriented development environment into a runtime application having a master object 

30 
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FIG. 3 
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FIG. 4 
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